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The invention is described in the following statement: 
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DIGITAL LICENSE SHARING SYSTEM AND METHOD 
FIELD OF THE INVENTION 

The present invention relates to digital rights management, and in 
particular to a system and method for sharing a single digital license amongst 
5 multiple devices. 

BACKGROUND OF THE INVENTION 

Today many service providers sell their digital content, such as digital 
music, Images, video, books and games, over computer networks. To protect 
commercial digital intellectual property and avoid digital piracy, Digital Rights 
10 Management (DRM) systems are needed that can be used to prevent 
unauthorized access to digital content and manage content usage rights. The 
core concept in DRM is the use of digital licenses. A license is a digital data file 
that contains content decryption keys and content usage rules. 

. In DRM, rather than buying content directly, users purchase licenses that 
5 grant certain rights to the content. Usage rules specify how the content should be 
used, such as copy permission, pay-per-view, a one-week rental, and so on. A 
license can be described using a rights expressing language, such as extensible 
rights Markup Language (XrML) that was selected by the Moving Picture Expert 
Group (MPEG) for the MPEG-21 Multimedia Framework. Some use scenarios for 
the usage rules are described in the XrML specification document, extensible 
rights i\/larl<up Language (XrML) 2.0 Specification, ContentGuard, 20 November, 
2001 . However, the specification does not specify mechanisms to support these 
scenarios. 

In current DRM implementations, encrypted content can be distributed 
using any communication medium, such as through a client/server system, super- 
distribution, digital audio/video broadcasting, or CDs, but without possession of a 
valid license, the content cannot be decrypted. The protected content can thus 
be distributed independently of any license. More specifically, when the user 
attempts to consume the. protected content, the player device will check if there 
exists a valid license for the content on the user's device. If the player cannot find 
the license, it will refuse to grant access to the content, and prompt the user to 
contact the license server to acquire a valid license. After the user provides 
information and/or payment that may be necessary to obtain the license, the 



license will be delivered to tlie user's device, and tlie protected content can be 
decrypted and used according to the usage terms and conditions in tlie license. 

In order to prevent digital piracy via transfer of riglits, most existing DRM 
solutions bind licenses to a particular device. The license cannot be transferred 
and used on another device. For example, if a user wants to watch a purchased 
movie at an alternative location, or listen to music on a portable device, the user 
must acquire a new license for each device, which is inconvenient for the user. 

The License Management Service (LMS), as disclosed for example In 
Backing Up and Restoring of DBM Licenses, Microsoft Corporation, 2000-2003 
uses a centralized server to manage the restoration of licenses in DRM. This 
service allows the user to transfer licenses to a new computer or back to the 
same computer after reformatting the hard disk, for example. The user must be 
connected to the Internet when the user tries to restore licences and a request 
from the application will be sent to the server. 

Under LMS, the user is only allowed to restore a license to a limited 
number of computers. Each time a license is restored, the server tracks the 
number of computers to which a license has been restored. If a limit is reached, 
the user cannot restore the license. Microsoft does not publish the technical 
details of this service, however it is apparent that LMS does not provide a 
satisfactory solution to the problem of sharing a license among multiple devices 
while ensuring that only one device can use the license at a time. 

The document Copy Prevention Scfieme for Rigtits Trading infrastructure, 
by Masayuki Terada and Hiroshi Kuno and Masayuki Hanadate and Ko Fujimura, 
NTT Laboratories, 2000, describes a generic copy prevention scheme for trading 
digital rights called FlexiToken. In this scheme, a digital right is represented using 
two types of information: the rights description object ahd the token object. The 
token object represents the "genuineness" of the rights object and is stored and 
circulated using tamper-proof devices such as smart cards. The rights object can 
be held in any storage medium, but to redeem the rights, the user must present 
the token of the rights to the service provider. 

The security of this scheme depends on the assumption that secret keys 
are managed securely and that the tamper-proof capability of smart cards is not 
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compromised. Thus, a digital riglit can be protected against alteration, forgery 
and reproduction. 

To prevent repudiation of rights transfer, FlexiToken assumes that neither 
participant flees from the other, i.e. the sender deletes the token from the original 
5 card after receiving the receipt from the receiver. However, this assumption may 
be violated if the operation of this procedure is interrupted either intentionally or 
accidentally. For example, a dishonest user may terminate the transaction after 
transferring the rights token from one card to another without deleting the original 
one. 

10 FlexiToken cannot be directly applied to DRM, because a digital license in 

DRIVI contains content keys, which need to be stored in a protected form. 
However, a rights object in FlexiToken does not contain content keys. 

An alternative scheme, the Extensible Cluster Protocol (xCP), is described 
in the IBM corporate document, IBM Response to DVB-CPT Call for Proposals for 

15 Content Protection & Copy Management: xCP Cluster Protocol, 2001. In xCP, 
digital content is cryptographically bound to a network of devices in a "cluster", 
which may be, for example, all of the devices in a user's household. Within a 
single cluster, digital content can be freely moved and copied from device to 
device, so that the consumer can access all the licensed content from these 

20 devices. The xCP Cluster Protocol prevents unauthorized content distribution 
outside of the cluster, for example from one household to another. 

This protocol requires that each device have a unique set of device keys 
and that peers in a cluster share a common media key block and a cluster ID. 
Devices use device keys and the media key block to calculate a common key. 

25 This key value will be used to decrypt the encrypted content key embedded in the 
content file. The security of this protocol largely depends on the assumption that 
the media key block is securely stored in one of the devices in the cluster that 
acts as a server to authorize other devices. 

Unlike most existing DRM systems in which digital content and licenses 

30 are stored and distributed separately, in the xCP scheme usage rules are stored 
in the clear parts of encrypted content, such as "copy once", "copy no more", and 
"copy never". Time-based usage rules, such as an elapsed time condition or 
calendar-based permission, are supported based on the assumption that the 



server has a secure clock. Count-based usage rules, such as a fixed number of 
player devices, require that the server have a secure hardware counter that 
prevents the user from restoring an old counter value or resetting usage counts. 
The xCP Cluster Protocol is. a hardware-based solution. Thus, for 
5 example, If user A s^lls an xCP-compliant device to user B, then In order for the 
device to worl< in user B's cluster, a strategy must be provided to enable the 
device to be embedded with the cluster ID specific to B's home network. 

US Patent Serial No. 6,372,974, assigned to Intel Corp, describes a 
portable music player capable of transferring music files directly to another such 
0 player, i.e. without the Intermediary of a PC or other intervening host. A method 
of transfer is disclosed that Is capable pf protecting digital rights by using a 
transfer protocol that results In the eventual deletion of the content on the sending 
player. Accordingly, the method Is intended to ensure that only one copy of the 
content exists at any given time. However, the method does not provide support 
5 for more sophisticated DRIVI features, and in particular does not provide for a 
license that may include content usage rules, and that may exist independently of 
encrypted content. 

Furthermore, it is not apparent from US 6,372,974 that the method 
disclosed provides adequate protection against communications failures that may 
result from accidental or intentional disconnection of the players during transfer. 
Without suitable safeguards to ensure atomicity of transfers (i.e. that in all 
circumstances either all or none of the transaction's operations are performed), 
such disconnection may result in the user either losing access to a playable copy 
of the content, or illegitimately obtaining an additional copy of the content. 

Published US Patent Application No. 2003/0004885, assigned to IBM 
Corp, describes a method for maintaining a chain of title when transferring digital 
property rights. The method consists in augmenting existing DRM information 
(e.g. a license) with additional fields Identifying the current owner and ownership 
history. When the license Is transferred, ownership is updated and digitally 
signed by the "seller", after which only the "buyer" is permitted to consume the 
licensed content or to transfer the ownership again. However, the method Is 
based on the assumption that a secure and reliable procedure for rights transfer 
Is available, and the document does not disclose any particular scheme for 
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achieving this, in particular, the IBM specification does not disclose a method for 
transferring a license, including a content decryption i<ey, between two devices 
and without the intermediary of a license server. 

US Patent Serial No. .5,629,980, assigned to Xerox Corp, discloses a 
5 system for controlling the use and distribution of digital works. The system 
includes trusted storage locations known as "repositories" in which digital works 
controlled by DRM usage rights are held. Accordingly, all player devices, as well 
as devices such as content servers, include such repositories. IVIethods are 
provided for describing and implementing a broad spectrum of possible usage 
10 rights, including lending rights and differing levels of copying rights. However, no 
methods are disclosed that provide for the secure, efficient and flexible transfer of 
licenses independently of encrypted content, such that it would be possible to 
maintain multiple copies of the content in untrusted storage, for example on 
multiple devices owned by a single consumer, while allowing only a single device 
15 to hold a license authorising playback of the content using that device. 

In summary, there is a need for a secure license-sharing system and 
method that allows a user to share a license among multiple devices while 
ensuring that only one device can use the license at a time: 

It is desirable that a license-sharing method ensures that a digital right can 
20 be protected against alteration, forgery and reproduction, while providing for 
protected content keys so that the method may be applied directly to DRM. 

Furthermore, it is a desired feature of a license-sharing scheme that it 
should not be unduly hardware dependent so that, for example, ownership of a 
player device may be transferred and/or physical location or connectivity of a 
25 device may be changed without requiring a specialised strategy to be employed 
to authorise the device for use by its new owner and/or in its new location. 

It is also desirable to provide a license-sharing scheme that is able to 
ensure that there is always exactly one device that has a valid copy of a license 
at the end of a license transfer procedure, regardless of any communication 
30 failure between two players, i.e. that the transfer procedure satisfies the atomicity 
property. 

Accordingly, it is an object of the present invention to mitigate the problems 
of the prior art by satisfying at least one of the aforementioned needs and desires. 
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It should be noted that any discussion of documents, devices, acts or 
knowledge in this specification is included to explain the context of the invention. 
It should not be taken as an admission that any of the material formed part of 
(common) general knowledge in the relevant art. 
5 SUMMARY OF THE INVENTION 

The inventors have recognised that it is possible to separate a digital 
license that confers specific usage rights within a DRM system from an 
entitlement of any particular device to exercise the usage rights. In prior art 
schemes, the usage rights and entitlement to exercise those rights are generally 
1 0 bundled together in the digital license, resulting in the binding of the license itself 
to a single device. By separating the rights from the entitlement, the inventors 
provide a method that enables the license to be held by a plurality of devices, 
while making it possible to ensure that only one device at any one time is actually 
enabled to exercise the usage rights. The license is therefore not bound to a 
15 specific device, but rather may be held by an unrestricted number of devices, 
whereas the entitlement to exercise the usage rights may be held by only a single 
device at any given time. 

Accordingly, in one aspect, the present invention provides, in a digital 
rights management system in which a digital license confers predetermined 
20 usage rights in relation to a digital content, a method of transferring the usage 
rights from a first content player application to a second content player 
application, including the steps of: 

a) associating with the first content player application a first status 
indication with respect to the digital license for indicating whether the first player 

25 application is entitled to exercise the usage rights conferred by the license; 

b) associating with the second content player application a second 
status indication with respect to the digital license for indicating whether the 
second player application is entitled to exercise the usage rights conferred by the 
license; 

30 c) transmitting a request for transfer of the usage rights from^ the 

second player application to the first player application; 

d) setting the first status indication to indicate that the first player 
application Is no longer entitled to exercise the usage rights; 



e) transmitting a response transferring the usage rights from the first 
player application to the second player application; and 

f) setting the second status indica.tion to indicate that the second 
application is henceforth entitled to exercise the usage rights; 

5 wherein the steps (c) to (f) are carried out in the stated order. 

Advantageously, the usage rights conferred by the license are thereby not 
bound to a single device or application, but may be transferred from one device to 
another, while at the same time ensuring that the license can only be used by a 
single device at any one time. Furthermore, the particular sequence of steps 
0 ensures that the transfer process is robust against intentional or unintentional 
failures of communication between the two applications, such that any 
interruption that occurs during the process cannot result in both applications 
• simultaneously acquiring the usage rights conferred by the license. 

Preferably, the first content player application executes on a first player 
5 device and the second content player application executes on a second player 
device. However, it will be appreciated that the two player applications may 
execute on a single device such as, for example, a general purpose PC. 

It is preferable that prior to the transfer, the first status indication indicates 
that the first content player application is entitled to exercise the usage rights. 
Clearly, if this is not the case no transfer of the rights can occur. It is also 
preferred that prior to the transfer, the second status indication indicates that the 
second content player application is not entitled to exercise the usage rights. 

In preferred embodiments, the step (e) must be successfully completed 
within a predetermined time following the completion of step (c), otherwise the 
transfer is aborted. Advantageously, the inclusion of such a timeout in the 
method ensures that a failure of communication between the two applications 
does not result in a deadlock of one or both applications. 

Step (e) may also include transmitting the digital license from the first 
player application to the second player application. This Is particularly 
advantageous if the second player application does not already have the license, 
since the second application is thereby immediately enabled to exercise the 
usage rights with respect to the digital content without the need to separately 
acquire the license itself. 
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Step (c) may include, after transmitting the request, setting the second 
status Indication to indicate that transfer of the usage rights has been requested. 
Transmitting the request may include transmitting a request message from the 
second application to the first application, wherein the message includes the 
5 value of the second status Indication. Accordingly, if the transfer is subsequently 
aborted after step (d) then the first and second status indicators will indicate that 
the second application has requested the usage rights whereas the first 
application is no longer entitled to exercise the usage rights. Advantageously, the 
applications are thereby able to verify that the transfer was aborted and negotiate 

1 0 for completion of the transfer of rights to the second application. 

Preferably, the first and second status indications are implemented as 
transaction flags In first and second tracking files associated with the first and 
second content player applications respectively. The transaction flags may be 
associated with the digital license by using a unique license identifier stored 

15 within the license as an index in the tracking file. Advantageously this enables 
each tracking file to store transaction flags associated with multiple digital 
licenses. It is further preferred that each entry in each tracking file includes a time 
stamp indicating when the license was last transferred to or from the 
corresponding application. 

20 In a preferred embodiment, the method further includes computing an 

authentication code that is a function of the values of all transaction flags in the 
tracking file each time any transaction flag in the tracking file is altered. The 
authentication code may be computed as a one-way hash function of the. 
concatenated values of all of the transaction flags. Preferably a secret key is 

25 associated with each of the first and second devices, and the value of the secret 
key is concatenated with the transaction flags before computing the hash 
function. Advantageously this prevents a malicious user from modifying the value 
of a transaction flag in the tracking file and recomputing the authentication code. 
In a particularly preferred embodiment, a secure monotonic counter Is 

30 associated with each device that is incremented each time any transaction flag In 
the tracking file Is altered, and the value of the counter is concatenated with the 
secret key and the transaction flags before computing the hash function. This 
protects the tracking file against replay attack. 
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Preferably, the steps of the method are executed in a tamper resistant 
secure computing environment including secure storage, and the secret key is 
held only within said secure storage. 

In another aspect, the present invention provides, In a digital rights 
5 management system in which a digital license confers predetermined usage 
rights in relation to a digital content, a system for transferring the usage rights 
from a first content player application to a second content player application, 
including: 

request transmitting means adapted for transmitting a request for transfer 
10 of the usage rights from the second player application to the first player 
application; 

first indication setting means adapted for setting a first status indication 
associated with said first content player application to indicate that the first player 
application is no longer entitled to exercise the usage rights; 
15 response transmitting means adapted for transmitting a response 

transferring the usage rights from the first player application to the second player 
application; and 

second indication setting means adapted for setting a second status 
indication associated with said second content player application to indicate that 

20 the second application is henceforth entitled to exercise the usage rights. 

Preferably, the request transmitting means includes computer software 
code including instructions to effect transmission of a request for transfer of the 
usage rights from, the second player application to the first player application, the 
first indication setting means includes computer software code including 

25 instructions to effect the setting of said first status indication to indicate that the 
first player application is no longer entitled to exercise the usage rights, the 
response transmitting means includes computer software code including 
instructions to effect transmission of a response transferring the usage rights from 
the first player application to the. second player application, and the second 

30 indication setting means includes computer software code including instructions 
to effect the setting of said second status indication to indicate that the second 
application is henceforth entitled to exercise the usage rights. 
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In another aspect, the present invention provides, in a digital rights 
management system, a method for generating a second digital license from a first 
digital license, wherein said first digital license confers predetermined usage 
rights in relation to a digital content upon a first digital content player application 
5 and said second digital license confers the usage rights upon a second digital 
content player application, said digital content being normally encrypted and only 
able to be decrypted using a digital content decryption key, the first and second 
digital licenses each including a validated portion and an unvalidated portion, 
wherein 

10 the validated portion of the first digital license includes characteristic 

information of the digital content decryption key, and 

the unvalidated portion of the first digital license includes the digital content 
decryption key encrypted using an encryption key associated with said first digital 
content player application, 
15 the method including the steps of: 

decrypting the digital content decryption key using a decryption key 
associated with the first digital content player application; 

using the decrypted digital content decryption key to generate the 
characteristic information of the digital content decryption key; 
20 verifying that the generated characteristic information matches the 

characteristic information included in the validated portion of the first digital 
license; and 

if the verification is successful, encrypting the digital content decryption key 
. using, an encryption key associated with said second digital content player 
25 application and including said encrypted key in the unvalidated portion of the 
second digital license. 

Advantageously, the method enables a license that was originally issued 
for use by the first player application to be transferred to the second player 
application without the need to contact the license issuer or other authority to ^ 
30 obtain a new license for use with the second player. Accordingly, It is possible to 
transfer the license while offline, since no connection to an outside license server 
is required. 
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Preferably, the validated portion of the first digital license is validated using 
a digital signature of a trusted authority. The trusted authority may be, for 
example, a license issuer. The validated portion may further include information 
relating to the usage rights conferred upon the player application. Preferably, the 
5 validated portion also includes a unique license identifier. 

It is preferred that the encryption and decryption keys associated with the 
first digital content player application are the public and private keys respectively 
of a first public/private key pair. It is also preferred that the encryption key 
associated with the second digital content player application Is the public key of a 
1 0 second public/private key pair. 

In preferred embodiments, the method may include the step of verifying 
that the validated portion of the digital licence has not been altered, and that the 
license has been legitimately acquired from the license issuer,' for example by 
verifying that the digital signature is correct with respect to the issuer and the 
15 contents of the validated portion of the license. Accordingly, if an attempt has 
been made to alter the license, for example to confer additional rights, or to forge 
a license, the player application may reject the license. 

It is preferred that the validated portion of the digital license includes 
characteristic information of the encrypted digital content, for example a hash of 
20 the encrypted digital content. Accordingly, the method may further include the 
steps of generating the characteristic information of the encrypted digital content 
and verifying that the generated characteristic information matches the 
corresponding information included in the validated portion of the digital license. 
Advantageously, this enables a' content player application to verify that the digital 
25 license corresponds with the digital content. 

The characteristic information of the digital content decryption key is 
preferably a hash of the digital content decryption key. In particularly preferred 
embodiments, a one-way, collision-free and pre-image resistant hash function is 
used, such that it is very unlikely that any two content decryption keys will have 
30 the same hash value. 

It is preferred that the device upon which the first digital content player 
application executes provides a tamper resistant secure computing environment 
including secure storage, and that the decrypted digital content decryption key 




12 

and the private key of the first digital content player appllcatiori are held only 
within said secure storage. 

In yet another aspect, the present invention provides, in a digital rights 
management system, a system for generating a second digital license from a first 
5 digital license, wherein said first digital license confers predetermined usage 
rights in relation to a digital content upon a first digital content player application 
and said second digital license confers the usage rights upon a second digital 
content player application, said digital content being normally encrypted and only 
able to be decrypted using a digital content decryption key, the first and second 
10 digital licenses each including a validated portion and an unvalidated portion, 
wherein 

the validated portion of the first digital license includes characteristic 
information of the digital content decryption key, and . 

the unvalidated portion of the first digital license includes the digital content 
15 decryption key encrypted using an encryption key associated with said first digital 
content player application, 

the system including: 

decrypting means for decrypting the digital content decryption key using a 
decryption key associated with the first digital content player application; 
20 generating means for using the decrypted digital content decryption key to 

generate the characteristic information of the digital content decryption key; 

verifying means for verifying that the generated characteristic information 
matches the characteristic information included in the validated portion of the first 
digital license; and 

25 encrypting means for checking if the verification is successful, and if so 

then encrypting the digital content decryption key using an encryption key 
associated with said second digital content player application and including said 
encrypted key in the unvalidated portion of the second digital license. 

Preferably, the decrypting means includes computer software code 

30 including instructions to effect decryption of the digital content decryption key, the 
generating means includes computer software code including Instructions to 
effect generation of the characteristic Information of the digital content decryption 
key, the verlfyrng means includes computer software code Including instructions 
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to verify that the generated characteristic information matches the characteristic 
information included In the validated portion of the first digital license, and the 
encrypting means include computer software code including Instructions to check 
if the verification is successful, and if so then to effect encryption of the digital 
content decryption key using an encryption key associated with said second 
digital content player application and including said encrypted key In the 
unvalidated portion of the second digital license. 

In order that the Invention might be more fully understood, embodiments of 
the invention will be described with reference to the accompanying drawings. 
Further optional and preferred features and advantages of the methods and 
systems of the present invention will become apparent from the following 
description of these preferred embodiments. However, the embodiments 
described herein below should not be considered as limiting the scope of the 
invention or any of the preceding statements. 
BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic diagram of digital rights management system 
according to a preferred embodiment of the invention; 

Figure 2 is an illustration of an arrangement that may be employed by a 
malicious user to gain unauthorised access to a license; 

Figure 3 illustrates an exemplary license transfer procedure according to a 
preferred embodiment of the invention; 

Figure 4 illustrates a license recovery procedure according to a preferred 
embodiment of the invention; 

Figure 5 is a schematic illustration of an. exemplary digital license 
according to the Invention; and 

Figure 6 is a schematic illustration of an exemplary track file entry 
according to the invention. 

DESCRIPTION OF PREFERRED EMBODIMENT 

Figure 1 is a schematic diagram of a digital rights management system 
100 according to a preferred embodiment of the Invention, The system includes 
two trusted player devices 102, 103, each of which includes a digital library 104, 
105, a license database 106, 107 and a secure hardware counter 108, 109. Each 
player device 102, 103 may be, for example, a portable music player, a digital 



14 

video player, or a general purpose personal computer with Installed software and 
hardware enabling it to be used to reproduce or display digital content. 

Each license database 106, 107 is a conceptual database, such as a file 
directory, on the respective device, which stores all licenses In a protected form 
5 and further includes a transaction track file that maintains a record of transaction 
flags of these licenses. Each digital library 104, 105 is a digital content repository 
on the user's device that stores digital items in a protected form. To decrypt and 
use content, there must be a valid license with a valid transaction flag in the 
license database 106, 107. Each counter 108, 109 is a secure, monotonically 
10 . increasing hardware counter that can be used to prevent replay attack. It will be 
incremented by one each time a license transfer happens. The player is a viewer 
responsible for content decryption and playback, and for providing an interface 
with which the user can request/transfer a license from/to another device. 

In one exemplary use scenario of the system, the user has acquired a 
15 license 110 from a license server and may have stored the license on a home 
PC, for example. If the user wishes to consume the content on multiple devices 
102, 103, the license must be transferred to the appropriate device. Transfer of a 
license may occur directly between the devices via a network connection such as 
a TCP/IP LAN, or a wireless connection such as an infrared link or a Bluetooth or 
20 802.11 radio frequency link. Alternatively, transfer of a license may be through 
the Intermediary of a mobile phone or other handheld device with wireless 
connections. Since the user may carry a mobile phone or other handheld device 
wherever he goes, Using such a device to facilitate license transfer enhances the 
convenience of the system. 
25 In the license sharing system and method of the invention, reliance is 

made upon a number of assumptions, as follows: 

A1. DRM protected content can be copied and distributed to any 
device. Note that such protected content cannot be consumed if 
there is no valid license on the device. 
30 A2« License transfers take place between two trusted player 

applications. A player is trusted if it enforces content usage rights 
with respect to the license. 



A3. Each trusted player has a public/private key pair and an 
authentication key. A trusted player's private key and 
authentication key are securely stored on a secure memory of the 
user's device, so that the user does not have any knowledge of 
these keys at any time. 

A4. The trusted player executes in a secure computing environment, 
and a malicious user cannot gain the content key and 
unprotected content when the content is being decrypted. 

A5. The trusted player application is tamper-resistant, i.e. it is 
impossible for the user to reverse engineer and tamper the 
software. 

A6. There exist secure audio paths between the trusted player and 
the display card and between the trusted player and I/O card. 
This assumption ensures that protected content files remain 
protected until the content reaches the output device. 
It will be appreciated by those skilled in the art that the foregoing 
assumptions are generally satisfied in a number of known devices and systems 
implementing DRM, and can be achieved using known technologies and 
methods. Accordingly, these assumptions are not limiting of the present 
invention. 

The system embodiment of fig. 1 satisfies a number of requirements in 
transferring a license from the first player 102 to the second player 103, as 
follows: 

R1. The digital license must be kept on the user's device in a 
protected form. This is because the license contains content 
decryption keys that should be hidden from the user. 

R2. The license transfer procedure must ensure that only authorised 
player applications can access the license. A potential threat is 
that all the nearby devices of a device may get the signal through 
wireless (or PC) broadcasting when the license is sent out from 
the device. 

R3. The license must be protected against unauthorized modification, 
Interception and illegal forgery during transaction. Figure 2 



. illustrates one arrangement that a malicious user may try to 
employ in order to gain unauthorised access to a license. A 
license is sent from a first device 202 to a second device 204, 
such as a general purpose PC. The license data is received via 
5 the network interface hardware 206, and processed by a network 

interface device driver software component 208 installed within 
the operating system of the device 204. An unmodified device 
driver would pass the license data to the player application 210 
without examining or processing its contents. However, the 
10 potential threat is that the user may modify the driver software 

208 on the device .204 so that the driver 208 may modify or block 
the received license, or even illegally forge a license. 
R4- The license transfer procedure must satisfy the atomicity 
property. Atomicity is: "Either ail or none of the transaction's 
15 operations are performed. If a transaction is interrupted by failure, 

then partial changes are undone". Atomicity in the license 
transfer procedure is to ensure that only one device has a valid 
copy of the license at the end of the transfer procedure 
regardless of any communication failure between two players. 
20 Each of the two trusted player devices 102, 103 in fig. 1 has a copy of the 

DRM protected content. A license is to be transferred between the two players. 
The players manage license transfers and storage. Each device keeps a 
transaction track file for the purpose of license transfer. Each license known to 
the player has a corresponding data entry in the track file that contains a 
25 transaction flag of the license. Only the player can validate the integrity of the 
track file using Its authentication key and read the records in the file. There are 
four types of transaction flags for the license: Active, Deactivated, Request and 
Recover. The meaning of these flags are described as follows: 

• Active: the license can be used by the player to decrypt the 
30 content; 

• Deactivated: the licence is deactivated, so the player cannot use it; 

• Request: the license is requested by one player application to 
another; and 
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• Recover: the transaction flag of the license is requested to be set to 
'Active ■ by one player application to another. 
Each device can have a copy of the license, but only the license with 
'Active' flag can be used by the player application to decrypt the content, 
5 According to the present example, A and B are two trusted player, 

applications executing on the devices 1 02 and 103 respectively, IDl is license Vs 
identifier. Req{A, S, L) is the license request that application B sends to A for 
license L 7 is a timeout value of the protocol. Figure 3 illustrates an exemplary 
license transfer scenario: license L is stored on the hard disk of the device 102 on 
10 which application A executes, and the transaction flag for L is 'Active'. 
Application 8 executing on player 103 requests the 'Active' license Lfrom A, 
Step ^: B^A: Req(>4, S, L), B writes {IDu *Flag=Requesf) 
Step 2: if Req(yA, S, L) = valid, A^ B: L,A writes .(/D^, 'Flag=Deactivated'); 
Else, A quits after timeout (T). ' 
15 Step 3: If L is valid, B stores L and writes {IDu 'Flag=Active'); Else, B quits 

after timeout (7). 

in step 1 , B writes {IDu 'Fiag;=Request') as the entry for L \n its transaction 
track file. The transaction flag 'Flag=RequesV reflects the current transaction 
state of L, that is, that application B has requested the active license. At this time 
20 Us entry in the transaction track file on application As device 102 is {IDu 
'Flag=Actlve'), 

In step 2, A receives and verifies the license request from B. If the request 
is found to be valid, A sends license L to B and writes {IDu *Flag=Deactivated') as 
the entry for L in its transaction track file. Here, 'Fiag=Deactivated' indicates that 

25 the license cannot be used any more, although L is still physically kept on A's 
device, i.e. A will refuse to use L to decrypt the content if A finds that L is marked 
as deactivated in the transaction track file. If A does not receive Req(>\, S, L) 
within time Tor the verification fails, A quits the transaction. 

In step 3, B receives and verifies L from A. If L is found to be valid, B 

30 stores L and sets the transaction flag for L as 'Active', I.e. the entry for L in Bs 
transaction track file becomes {IDu 'Flag=Active'). Othenwise, if the verification 
fails or B does not receive the license from A within time T after sending Req(>4, 
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e, L), B quits the transaction. Application B may then attempt to request the 
license again, starting from step 1 . 

Preferably a license recovery protocol is implemented that is similar to the 
license transfer procedure. Figure 4 shows a license recovery scenario: both A 
5 and B have a copy of the licence L on their hard disks. The transaction flag for L 
is 'Active' on Bs device, but is 'Deactivated' on As device. A requests that Us 
transaction flag on its device to be set to 'Active'. 

In this procedure, instead of writing {IDu 'Flag=Requesf ), A writes (IDL, 
*Flag=Recover*) as the entry for L in its transaction track file after sending license 

10 recovery request to fi. The transaction flag 'Recover' indicates that L is physically 
stored on As hard disk but cannot be used, and A requests the 'Active* flag for L 
from B. After B receives and verifies As license recovery request, it will set the 
transaction flag for L on its device from 'Active' to 'Deactivated' and send a 
respond message to A, B will not be able to use the license. The entry for L In 

15 As transaction track file will become {IDl, 'Flag= Active'), so L can then be used 
by A to decrypt the content. 

It is to be noted that the difference between the license recovery procedure 
and the license request procedure is that in license recovery, A already has a 
copy of the license L that is known by A to be valid, and thus it is not necessary 

20 for B to send L to A, or for A to verify the license. 

In known DRM implementations, a license contains content ysage rules 
and the content key. When the license is distributed from the license server to 
the user's device, the content key should not be transiferred in clear text. Usually, 
the license issuer encrypts the content key with the public key of the player on the 

25 user's device. Each player application has a unique public/private key pair, thus 
each license is generated uniquely for a specific player on the user's machine. 
For example, in the DRM scheme described in the document Architecture of 
Windows Media Rigfits Manager published by Microsoft Corporation, 2003, the 
protected content key and usage rights are grouped In a license that is signed by 

30 the license issuer with its private key. This Is to ensure that the license has not 
been tampered, with and to prove that the license was purchased from the issuer. 

The disadvantage of this scheme is that the license can only be used by 
the player application to which it was Issued. In order to consume the content on 
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a different player, the user must request or purchase a further license. In at least 
preferred embodiments, the present invention provides a license structure that 
may be employed to avoid this disadvantage, and thus enable the direct transfer 
of a license between devices. 
5 The trusted player has a public key PUBj_P and corresponding private key 

PRLP, The license issuer has a public key PUB J and corresponding private key 
PRLL The license issuer generates a license L that includes metadata for the 
content and the content key CK encrypted with player's public key and usage 
rules, and then signs the license with its private key. That is, the Issuer generates 
1 0 a signed license as follows: 

Signed L=L\\SpRu{L) 
L = Metadata || EpubAOK) \\ Usage Rules 
where S() is a signature algorithm, E() is an asymmetric encryption algorithm, and 
'II* denotes concatenation. The signed license may then be delivered to the 

1 5 trusted player over a public channel. 

However, a potential problem arises if the above approach is used to 
encrypt the content key and construct the license. Suppose that A and B are two 
trusted player applications. Their public keys can be denoted as PUB_A and 
PUB_B respectively. Player A has the license L containing encrypted content key 

20 EpuB^CK) signed by the issuer / using PRU, A is to transfer the license to B, 

Before the transfer procedure, A needs use its private key to decrypt the 
encrypted content key and then re-encrypt the content key using player Bs public 
key. That is, A must generate Epub^CK) and use it to replace Epub^CK) in L so 
that B can decrypt and get the content key once the license is transferred from A 

25 to a The problem in this scenario is that the license integrity will be 
compromised, because of the change in the encrypted content key part in the 
license is from Epub_a{CK) to Epus^CK). When player B checks the integrity of 
the license according to the license issuer's signature, the verification will fail, 
since when the license was signed it contained Epub^a{CK), 

30 A new license structure is therefore proposed for use with preferred 

embodinients of the invention. Figure 5 illustrates schematically a license 500 
according to a preferred embodiment in which the license is split into two parts 
501 , 502. The first part 501 of the license 500 includes: a cryptographic hash 504 



20 

of the encrypted content, the hash value 506 of the content key, the usage rules 
508, and metadata 510. The second part 502 of the license 500 includes the 
content key encrypted with the public key of the player application 514. The first 
part of the license is digitally signed 512 by the Issuer to enable its integrity and 
5 authenticity to be verified. The reason for constructing the license in this way Is to 
prevent usage rules from unauthorized modification and to ensure that the 
issuer's signature will work properly when the content key is encrypted with 
another player's public key during license transfers. 

The question arises as to what happens in the case of a dispute when the 

1 0 user claims that the license issuer put the wrong content key in the license? To 
avoid such dispute, the hash function must be one-way, collision-free and pre- 
image resistant, so it would be very unlikely that the license issuer will generate 
two content keys with the same hash value. 

When a player receives the license, it will: 

15 • verify the signature 512 of the first part of the license; 

• verify the hash 504 of the content; 

• decrypt the encrypted content key 506 using its private key; and 

• pass the value of the key to the hash function. 

If the computed result is the same as the hash value 506 contained in the license, 
20 the player will accept the license. Othenwise, the license will be rejected and the 
player will contact the license server for license reissue. If the license is accepted 
but the key cannot be used to decrypt the content, the license issuer needs to 
reissue the license that contains the correct content key. 

To uniquely identify a license, a licence identifier 516 may be included in 
25 the first part of the license. Before decrypting the content, the player needs to 
find the corresponding entry in the transaction track file, which may be done by 
using the unique license identifier 516 as a key in the track file. If the transaction 
flag of the license is 'Active', the player will be permitted to use the content key to 
decrypt the content 

30 The discussion now turns to a more detailed description of the format of 

the transaction track file. The transaction track file keeps a record of the current 
transaction state of the licenses on the user's machine. When the license is 



21 

delivered -to the user's device for the first time, the player application will write an 
entry for the license to the track file if the license integrity is verified. 

To prevent track entries from undetectable manipulation or deletion, in the 
exemplary embodiment a Message Authentication Code (MAC) is attached to the 
5 file based on a secret key held by the player. Each license must have a unique 
entry in the track file that contains the transaction flag of the license. Every time 
the player updates a track entry, it increments the secure monotonic counter, e.g. 
108, 109, and includes the counter value in the MAC with the file. If the license is 
physically deleted from the hard disk, its track entry will be deleted and the MAC 
10 will be updated automatically. If the license is physically stored on the hard disk 
of the device but there is no track entry for that license, the player will detect 
unauthorised deletion of the track entry and refuse to transfer the license to 
another device. 

Figure 6 illustrates the format of an exemplary track file entry 600, 
15 including a unique license identifier 602, a transaction flag 604, and a timestamp 
606 that is maintained to reflect the last time the entry 600 was updated. 

If the license identifier 602 in the track entry 600 matches with the license 
identifier 516 in a license, then the track entry corresponds to the license. In the 
exemplary embodiment described herein there are four types of transaction flags: 
20 'Active', 'Deactivated', 'Request' and 'Recover'. The timestamp 606 records the 
time when a transfer of the corresponding license last occurred, and hence is the 
time at which the transaction flag was last updated. 

A MAC based on a secret key is used to prevent unauthorised tampering 
of the track file. In the exemplary embodiment, the player's authentication key is 
25 used for MAC computation. Suppose that the authentication key is K and 7/ (/ = 
1 , 2, n) is the Ah entry of the track file, then the value of the MAC is: 

MAC = H{K\\ Counter Value || Ti || |1 ... || Tn) 
where HQ is a one-way hash function and || denotes concatenation. 

The transaction track file is different from an audit log as described in the 
30 literature of the art. According to the definition of "log" provided in M Ruffin, A 
.Survey of Logging Uses, University of Glasgow (Scotland), Fide2 Report 94-82, 
February 1994, "a log is an append-only write store and is a plain file where data 
are stored sequentially as they arrive". In the exemplary embodiment, there is 
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only one entry in the track file for a license with a specific license identifier. When 
the license is distributed to the user's device for the first time, the player will 
create a new data entry for the license. The transaction flag for this license will 
be set to 'Active'. When a license transfer happens, the player will read the 
5 license identifier in the transferred license first and then search for the position of 
the entry for the license in the track file according to the identifier. The player will 
update the transaction flag and the timestamp of the license in the track entry 
after the license has been transferred to another device. 

The security properties of the preferred embodiment of the invention are 
1 0 analysed below by reference to the requirements R1 -R4 . 

Requirement R1 is satisfied, i.e. content keys In the licenses are kept in 
encrypted form on the user's device. Only the player application can decrypt 
encrypted content key using its private key. 

Requirement R2 is satisfied. Unauthorised player applications will not be 
15 able to gain access to a license through wireless or PC broadcasting, because 
the content key in the license is sent to an authorised recipient B in an encrypted 
form using Bs public key. Only B has the knowledge of the corresponding private 
key and thus only B is able to decrypt the encrypted content key. 

Requirement R3 is satisfied. Unauthorised modification, forgery and 
20 interception of the license can be prevented, because the integrity of the usage 
rules can be verified according to the issuer's digital signature in the license. 

Requirement R4 is satisfied. After a license transfer procedure takes 
place, only one device has the license with 'Active' flag. This properly is analysed 
for a number of specific cases of license transfer from player application A to 
25 player application S, as follows. 

Case 1: There is no communication problem between A and B, 
Exchanged messages are not disrupted by an attacker. 

The protocol runs successfully. At the end of the license transfer, only B 
possesses the license, and has a corresponding track file entry with the 'Active' 
30 flag. 

Case 2: A fails to receive the license request from B in step 2. . 
The protocol aborts after time out T. B does not obtain the license, L is 
still kept on A's device. The transaction entry for L on As device is unchanged. 
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Case 3:. B fails to receive the license from A in step 3. 
The protocol aborts after time out T, The transaction flag for L in the track 
file on As device is marlced as deactivated, so A cannot use L any more. 
However, B can get the license from A through a negotiation procedure, I.e. B 
5 sends the licence request to A again, starting from step 1 . This licence request 
needs to include the current transaction flag of L in the track file on S, which 
should be 'Request'. A will check the license request in the negotiation 
procedure. Since L is still physically stored on As device, A will send L to S 
again if the verification is successful. Finally, B will get license L and set the 
10 transaction flag for L as 'Active', so that B cannot send a valid license request to 
A again. • 

Moreover, the inventive system can prevent replay attack. Suppose that a 
. malicious user has some licenses with 'Active' flag on his device. The user may 
take a snapshot of the current state of the track file, perform one or more license 
15 transfers to another device and finally restore the snapshot, removing all records 
that reflect license transactions since the snapshot. However, the player is able 
to detect this attack because the secure counter is incremented once for each 
, transfer, Upon the user restoring the snapshot of the track file, the counter 
cannot be restored by the user to its value prior to the transactions. Accordingly, 
20 . the calculated MAC value will be inconsistent with the restored MAC value, due to 
the changed counter value. 
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PRELIMINARY STATEMENTS OF INVENTION ARE AS FOLLOWS: 



1. In a digital rights management system in which a digital license confers 
predetermined usage rights in relation to a digital content, a method of 
transferring the usage rights from a first content player application to a second 
content player application including the steps of: * • 

a) associating with the first content player application a first status 
indication with respect to the digital license for indicating whether the first player 
application is entitled to exercise the usage rights conferred by the license; 

b) associating with the second content piayer application a second 
status indication with respect to the digital license for indicating whether the 
second player application is entitled to exercise the usage rights conferred by the 
license; 

c) transmitting a request for transfer of the usage rights from the 
second player application to the first player application; 

d) setting the first status indication to indicate that the first player 
application is no longer entitled to exercise the usage rights;. 

e) transmitting a response transferring the usage rights from the first 
player application to the second player application; and 

f) setting the second status indication to indicate that the second 
application is henceforth entitled to exercise the usage rights; 

wherein the steps (c) to (f) are carried out in order. 

2. Preferably, the step (e) must be . successfully completed within a 
predetermined time following the completion of step (c), otherwise the transfer is 
aborted. 

3. Step (e) may also include transmitting the digital license from the first 
player application to the second player application. 

4. Step (c) may include, after transmitting the request, setting the second 
status indication to indicate that transfer of the usage rights has been requested. 
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5. Transmitting the request may include transmitting a request message from 
tlie second application to the first application, wherein the message includes the 
value of the second status indication. 

6. Preferably, the first and second status indications are implemented as 
transaction flags in first and second tracking files associated with the first and 
second content player applications respectively. 

7. Preferably, the method further includes computing an authentication code 
that is a function of the values of all transaction flags in the tracking file each time 
any transaction flag in the tracking file is altered. 

8. . The authentication code may be computed as a one-way hash function of 
the concatenated values of all of the transaction flags. 

9. Preferably a secret key is associated with each of the first and second 
devices, and the value of the secret key is concatenated with the transaction flags 
before computing the hash function. 

10. It is further preferred that a secure monotonic counter is associated with 
each device that is incremented each time any transaction flag in the tracking file 
is altered, and the value of the counter is concatenated with the secret key and 
the transaction flags before computing the hash function. 

11. Preferably, the steps of the method are executed in a tamper resistant 
secure computing environment including secure storage, and the secret key is 
held only within said secure storage. 
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12. In a digital rights management system in which a digital license confers 
predetermined usage rights in relation to a digital content, a system for 
transferring the usage rights from a first content player application to .a second 
content player application including: 

request transmitting means for transmitting a request for transfer of the 
usage rights from the second player application to the first player application; 

first indication setting means for setting a first status indication associated 
with said first content player application to indicate that the first player application 
IS no longer entitled to exercise the usage rights; 

response transmitting means for transmitting a response transferring the 
usage rights from the first player application to the second player application; and 

second indication setting means for setting a second status indication 
associated with said second content player application to indicate that the second 
application is henceforth entitled to exercise the usage rights. 

13. In a digital rights management system, a method for generating a second 
digital license from a first digital license, wherein said first digital license confers 
predetermined usage rights in relation to a digital content upon a first digital 
content player application and said second digital license confers the usage rights 
upon a second digital content player application, said digital content being 
normally encrypted and only able to be decrypted using a digital content 
decryption key, the first and second digital licenses each including a validated 
portion and an unvalidated portion, wherein 

the validated portion of the first digital license includes characteristic 
information of the digital content decryption key, and 

the unvalidated portion of the first digital license includes the digital content 
decryption key encrypted using an encryption key associated with said first digital 
content player application, 

the method including the steps of: 

decrypting the digital content decryption key using a decryption key 
associated with the first digital content player application; 
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using the decrypted digital content decryption key to generate the 
characteristic information of the digital content decryption key; 

verifying that the generated characteristic infornnatlon matches the 
characteristic information included In the validated portion of the first digital 
license; and 

If the verification is successful, encrypting the digital content decryption key 
using an encryption key associated with said second digital content player 
application and including said encrypted key in the unvalidated portion of the 
second digital license. 

14. Preferably, the validated portion of the first digital license is validated using 
a digital signature of a trusted authority, such as a license issuer, ' 

15. It is preferred that the encryption and decryption keys associated with the 
first digital content player application are the public and private keys respectively 
of a first public/private key pair and that the encryption key associated with the 
second digital content player application Is the public key of a second 
public/private key pair. 

16. Preferably, the method includes the step of verifying that the validated 
portion of the digital license has not been altered, and that the license has been 
legitimately acquired from the license issuer, for example by verifying that the 
digital signature is correct with respect to the issuer and the contents of the 
validated portion of the license. 

17. It Is preferred that the validated portion of the digital license includes 
characteristic information of the encrypted digital content, for example a hash of 
the encrypted digital content and that the method further includes the steps of 
generating the characteristic information of the encrypted digital content and 
verifying that the generated characteristic information matches the corresponding 
information included in the validated portion of the digital license. 
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1 8. The characteristic information of the digital content decryption key is 
preferably a hash of the digital content decryption key, and it is particulariy 
preferred that a one-way, collision-free and pre-image resistant hash function is 
used, such tliat it is very unlikely that any two content decryption keys will have 
the same hash value. 

19. It is preferred that the device upon which .the first digital content player 
application executes provides a tamper resistant secure computing environment 
including secure storage, and that the decrypted digital content decryption key 
and the private key of the first digital content player application are held only 
within said secure storage. 

20. In a digital rights management system, a system for generating a second 
digital license from a first digital license, wherein said first digital license confers 
predetermined usage rights in relation to a digital content upon a first digital 
content player application and said second digital license confers the usage rights 
upon a second digital content player application, said digital content being 
normally encrypted and only able to be decrypted using a digital content 
decryption key, the first and second digital licenses each including a validated 
portion and an unvalidated portion, wherein 

the validated portion of the first digital license includes characteristic 
information of the digital content decryption key, and 

the unvalidated portion of the first digital license includes the digital content 
decryption key encrypted using an encryption key associated with said first digital 
content player application, 

the system including: 

decrypting means for decrypting the digital content decryption key using a 
decryption key associated with the first digital content player application; 

generating means for using the decrypted digital content decryption key to 
generate the characteristic information of the digital content decryption key; 

verifying means for verifying that the generated characteristic information 
matches the characteristic information included in the validated portion of the first 
digital license; and 
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encrypting means for checking If the verification is successful, and If so 
then encrypting the digital content decryption key using an encryption key 
associated with said sedond digital content player application and Including said 
encrypted key In the unvaildated portion of the second digital license. 
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